Shell extensions for an operating system

ABSTRACT

An operating system provides extensions through which application developers may extend the capabilities of a shell of the operating system. For example, application developers may add menu items to context menus for objects that are visible within an integrated system name space. In addition, developers may add property sheet pages for such objects. Application developers also have the option of providing per-instance icons for each instance of an object. Application developers may provide data object extension handlers for customizing data sources on a per-object class basis and may provide drop target extension handlers on a per-object class basis to customize drop target behavior. Developers may additionally provide copy-hook handlers to regulate file system operations on objects. Developers may also extend the functionality provided by the shell of the operating system by adding their own custom name spaces to the integrated system name space. The mechanism provided by the operating system to add such a name space is polymorphic and transparent to users.

CROSS-REFERENCE TO RELATED INVENTIONS

This is a continuation of prior application Ser. No. 09/392,344, filedSept. 8, 1999, U.S. Pat. No. 6,160,550 which is a divisional of priorapplication Ser. No. 09/179,240, filed Oct. 26, 1998, now U.S. Pat. No.6,008,806, which in turn is a continuation of prior application Ser. No.08/355,410 filed Dec. 13, 1994, now U.S. Pat. No. 5,831,606, priorityfrom the filing dates of which is hereby claimed under 35 U.S.C. § 120.

FIELD OF THE INVENTION

The present invention relates generally to data processing systems and,more particularly, to shell extensions for an operating system.

BACKGROUND OF THE INVENTION

Conventional operating systems include shells that provide userinterfaces. Unfortunately, such shells are often limited in theircapabilities and in the flexibility of options that they provide to anapplications developer. For example, such conventional operating systemsoften provide shells that define context menus for each file systemobject. The list of menu items and associated operations provided by theshells for the context menus are often limited. Moreover, the menu itemscannot be changed by applications.

Conventional shells are often additionally limited in that theypredefine property sheet pages for file system objects. The propertysheet pages are user interface elements that display property values forthe associated file system objects and typically allow a user to changesome of the displayed property values. Each property sheet page isassociated with a subset of related properties for the objects.

The shells of conventional operating systems are further limited in thatthey provide predefined icons only for file types or objects classes.These shells do not facilitate the use of per-instance icons that areassociated with each instance of an object or file. The shells of theconventional operating systems are further limited in that they onlyprovide access to objects in the file system name spaces and provide noeasy mechanism for integrating additional name spaces into the system.

Conventional operating systems are also limited as to drag-and-dropoperations. In particular, applications have no ability to customize thefunctionality of a drop based upon a file object type. in conventionalsystems. Further, these conventional operating systems provide noability to customize source objects in drag-and-drop operations.

SUMMARY OF THE INVENTION

The above-described difficulties encountered by shells of conventionaloperating systems are overcome by the present invention. In accordancewith a first aspect of the present invention, a method is practiced in adata processing system that includes a video display and an object thathas an associated context menu for specifying operations that may beperformed relative to the object. The data processing system alsoincludes an operating system with a shell that specifies predefined menuitems in the context menu. In this method, a database of entries holdingconfiguration information is provided within the data processing system.Menu items that are not predefined by the shell are registered in thedatabase so that the menu items are included in the context menu. Eachentry that is registered in this fashion includes an identification ofcode that is to be executed when the menu item of the object is selectedby a user.

In accordance with a further aspect of the present invention,configuration information about a context menu handler is registered indatabase configuration information in a data processing system. A usermakes a request and, in response to the request, the database is.accessed to obtain configuration information about the context. menuhandler. The context menu handler is invoked to add menu items to acontext menu of an object. A shell of an operating system provides atleast one menu item for the context menu, but the context menu handleris used to add at least one additional menu item to the context menu forthe object.

In accordance with an additional aspect of the present invention, adatabase of registration information is stored in a memory means in adata processing system. A representation of a per-instance icon for afile is also stored in the memory means. The representation of theper-instance icon is registered in the database of registrationinformation along with an icon handler. The icon handler is used to findthe representation of the per-instance icon. A request to display theper-instance icon is received arid, in response, the database isaccessed to locate the icon handler. The icon handler then provides theper-instance icon to the operating system, which displays theper-instance icon on the video display.

In accordance with another aspect of the present invention, a databaseof registration information is stored in a memory means of a dataprocessing. system. An object that has associated properties is providedwithin the data processing system. The data processing system includes aprocessing means that runs an operating system with a shell. The shellof the operating system provides at least one property sheet page forthe object. A property sheet handler is registered in the database. Theproperty sheet handler adds additional property sheet pages for theobject. When a request to add at least one property sheet page for theobject is received, the property sheet handler is used to add at leastone property sheet page for the object.

In accordance with yet another aspect of the present invention, a dataprocessing system includes a memory means, a video display and aprocessing means. The memory means holds an object and an operatingsystem that includes a shell. The memory means also holds a registry forholding registration information. The registry holds at least one shellextension handler for extending capabilities of the shell of theoperating system. The data processing system further includes aprocessing means for running the operating system and the shellextension handler. The shell extension handler may be a number ofdifferent types of handlers, including a context menu handler, an iconhandler, a property sheet handler or a shell name space extensionhandler.

In accordance with another aspect of the present invention, a method ispracticed in a data processing system that has a video display and anoperating system that includes a file system for performing file systemoperations on file system objects. In this method, a copy-hook handleris provided to indicate whether a file system operation should beperformed on a selected file system object. In response to a request toperform a specified file system operation on the selected file systemobject, the copy-hook handler is called to generate indication ofwhether the specified file system operation should be performed on theselected file system object. The indication that is generated by thecopy-hook handler is used to determine whether to perform the specifiedfile system operation on the selected file system object.

In accordance with a further aspect of the present invention, a videodisplay displays a representation of a source object and arepresentation of a target object for a drag-and-drop operation. A dataobject extension handler is provided to customize the source object todetermine a format for a data that is to transferred when adrag-and-drop operation is performed on the source object in response toa user using an input device. A drag-and-drop operation is initiated inresponse to the user using the input device. This drag-and-dropoperation drags the representation of the source object to be positionedover the representation of the target object. The data object extensionhandler is invoked to determine the format for the data that is to betransferred from the source object in the drag-and-drop operation. Therepresentation of the source object is dropped on the representation ofthe target object in response to the user using the input device tocomplete the drag-and-drop operation.

In accordance with yet another aspect of the present invention, a droptarget extension handler is provided for customizing behavior of atarget object when a drop occurs on the target object. The drag-and-dropoperation is initiated on the source object in response to a user usingan input device. In particular, the representation of the source objectis dragged to be positioned over the representation of the targetobject. When a user drops the representation of the source object on therepresentation of the target object, the drop target extension handleris invoked to determine the behavior of the target object in response tothe drop.

In accordance with an aspect of the present invention, a method isperformed on a data processing system that has an operating system andclasses of objects. A shell extension handler is provided for one of theclasses of objects to extend the functionality of the shell relative tothat class of objects. The shell extension handler is independent of theoperating system and may be provided, for instance, by an application,program. The shell extension handler is invoked to extend thefunctionality of the shell for an object in the class of objects forwhich the shell extension handler is provided.

In accordance with an additional aspect of the present invention, amethod is practiced in a data processing system that has a video displayand an operating system. The operating system includes a name spacemechanism for providing a name space of objects, including file systemobjects. The operating system also includes a name space viewer forviewing objects in the name space on the video display. In this method,a name space extension is provided by an application program to addnon-file system objects to the name space. The name space extension isused to add these non-file system objects to the name space and the namespace viewer is then used to view at least one of the non-file systemobjects that have been added by the name space extension.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing aspects and many of the attendant advantages of thisinvention will become more readily appreciated as the same becomesbetter understood by reference to the following detailed description,when taken in conjunction with the accompanying drawings, wherein:

FIG. 1 is a block diagram of a data processing system that is suitablefor practicing a preferred embodiment of the present invention;

FIG. 2 is a flow chart that provides an overview of the steps that areperformed to extend the functionality of an operating system shell inaccordance with the preferred embodiment of the present invention;

FIG. 3 is a flow chart of the steps that are performed to add verbs to acontext menu in accordance with the preferred embodiment of the presentinvention;

FIG. 4 is a flow chart showing the steps that are performed to adddynamic verbs to a context menu in accordance with the preferredembodiment of the present invention;

FIG. 5 is a flow chart showing the steps that are performed todynamically add verbs to a context menu in accordance with the preferredembodiment of the present invention;

FIG. 6 depicts illustrative property sheets for an object;

FIG. 7 is a flow chart showing the steps that are performed to addadditional property sheet pages for an object;

FIG. 8 is an example of a menu that has a command for adding propertysheets in accordance with the preferred embodiment of the presentinvention;

FIG. 9 is a flow chart illustrating in more detail how property sheetsare added for an object in accordance with the preferred embodiment ofthe present invention;

FIG. 10 is a flow chart showing the steps that are performed to useper-instance icons for an, instance of an object in accordance with thepreferred embodiment of the present invention;

FIG. 11 is a flow chart showing in more detail the steps that areperformed to register a per-instance icon handler in the preferredembodiment of the present invention

FIG. 12 is a flow chart illustrating the steps that are performed to usea copy hook handler in accordance with the preferred embodiment of thepresent inventions,

FIG. 13 is a flow chart illustrating the steps that are performed toutilize a data object extension handler in accordance with the preferredembodiment of the present invention;

FIG. 14 is a flow chart illustrating the steps that are performed to usea drop target extension handler in accordance with the preferredembodiment of the present invention;

FIG. 15 is an example of an explorer window used in the preferredembodiment of the present invention;

FIG. 16 is a flow chart showing the steps that are performed to addadditional name spaces to the explorer name space in the preferredembodiment of the present invention;

FIG. 17 is a flow chart of the steps that are performed to add a shellfolder object to the explorer name space; and

FIG. 18 is a flow chart showing the steps that are performed to displaythe contents of objects in a newly added name space in the preferredembodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

The preferred embodiment of the present invention extends thecapabilities provided by a shell of an operating system to allow anapplication developer to customize context menus, add property sheetpages for objects and provide per-instance icons for objects. Further,the preferred embodiment of the present invention facilitates thecustomization of drop behavior and the customization of source objectsin drag-and-drop operations on a per-object type basis. A copy-hookhandler is provided to enable an application to grant or withholdapproval of copy, delete, move or rename commands on objects. Inaddition, the preferred embodiment of the present invention facilitatesthe addition of new name spaces to a name space that is visible througha browsing system-provided tool (known as the “explorer”). These shellextensions allow developers to customize to better suit the needs oftheir users.

The preferred embodiment of the present invention is practiced in anobject-oriented environment that supports the “MICROSOFT” OLE 2.01protocol developed by Microsoft Corporation of Redmond, Wash. In orderto fully understand the preferred embodiment of the present invention,it is helpful to review some of the fundamental concepts employed within“MICROSOFT” OLE 2.01.

An “object class” is the definition of both a data structure andfunctions that manipulate the data structure. An “object” is an instanceof an object class. A related “MICROSOFT” OLE 2.01 concept is that of an“interface.” An interface is a group of semantically-related functionsthat are organized into a named unit. The name of the unit is theidentifier of the interface. Interfaces have no instantiation in thatthe interface does not include code for implementing the functions thatare identified in the interface; rather, the interface specifies a setof signatures for functions. “Instantiation” refers to the process ofcreating in-memory structures that represent an object so that theoperations can be invoked on the object. When an object “supports” aninterface, the object provides code for the function specified by theinterface. Hence, an object that supports an interface is responsiblefor providing the code for implementing the functions of the interface.The code that is provided by the object must comply with the signaturesspecified by the interface.

The “MICROSOFT” OLE 2.01 protocol also provides “monikers”. A moniker isa composite name for an object that includes a pointer to the object.More formally, a moniker is an object that supports the predefinedIMoniker interface. The IMoniker interface includes a function forbinding the moniker to the object to which the pointer of the monikerpoints. Binding causes an object to be placed in a running state so thatthe services supplied by the object may be invoked.

The shell extensions are implemented as shell extension, dynamic linklibraries (DLLs). The shell extension DLLs are implemented byapplications and constitute instances of interfaces. These shellextension DLLs are called when needed to extend the functionality of theshell as required by the application. The preferred embodiment of thepresent invention provides context menu handlers, icon handlers,property sheet handlers, copy-hook handlers, name space extensionhandlers, data object extension handlers, and drop target extensionhandlers. Each of these handlers will be described in more detail below.

FIG. 1 is a block diagram of a computer system 10 that is suitable forpracticing the preferred embodiment of the present invention. Thecomputer system 10 includes a central processing unit (CPU) 12 that isconnected to a number of input/output devices, including mouse 14,keyboard 22 and video display 24. The computer system 10 also includes anetwork interface 16 for interfacing the computer system 10 with anetwork. Memory 18 and secondary storage 20 store data and code. Thememory 18 holds a copy of an operating system 26 that includes aregistry 28 for holding configuration information.

The registry 28 is organized as a hierarchically structured tree and isroughly analogous to the registry provided by the “MICROSOFT” WINDOWS NToperating system. Each node of the tree is identified by a key namecomposed of ASCII characters. Keys may contain other keys, known assubkeys. The registry has a predefined root key calledHKEY_(—CLASSES)_ROOT. At the same level of the hierarchy are threepredefined keys: HKEY_LOCAL_MACHINE, HKEY_CURRENT_CONFIG and HKEY_USER.Each of these predefined keys acts as a root of a separate subtree inthe registry. The subtree associated with HKEY_LOCAL_MACHINE holdsnon-user specific information about the computer system. TheHKEY_CURRENT_CONFIG key serves as the root of a subtree that holdsnon-user specific configuration information that pertains to hardware.Lastly, the HKEY_USER key is at the root of a subtree that. holds userspecific configuration information. The registry 28 is used by numerousapplications, such as will be described below.

FIG. 2 is a flowchart that provides an overview of the steps that areperformed to facilitate the shell extensions within the preferredembodiment of the present invention. Initially, objects on which theshell extensions operate and shell extension handlers must be providedwithin the memory 18 of the computer system 10. The shell extensionhandlers are then registered within the registry 28 (step 32) so thatthe computer system 10 is aware of the extension handlers and mayutilize them. These shell extension handlers are then used to providethe desired shell extensions (step 34). The shell extensions extend thefunctionality provided by the operating system to aid developers ofapplications.

The features of the shell extensions may be implemented, by performingthe steps shown in FIG. 2. In step 32, the shell extension handlers mustbe registered in the registry 28. Set forth below is an example of theformat of the registry 28 for a word processor application to supportthese features.

1: .doc = Awordprocessor 2: AWordProcessor = A Word Processor 3: shell =open print preview 4: open 5: commnand = c:\aword\aword.exe %1 6: print7: command = c:\aword\aword.exe /p %1 8: printTo 9: command =c:\aword\aword.exe /p %1%2%3 10: preview = Pre&view 11: command =c:\aword\aword.exe /r %1 12: shellex 13: ContexMenuHandlers = ExtraMenu14: ExtraMenu = (00000000-1111-2222-3333-00000000000001) 15:PropertysheetHandlers = SummaryInfo 16: SummaryInfo =(00000000-1111-2222-3333- 00000000000002) 17: IconHandler =00000000-1111-2222-3333-00000000000003) 18: DefaultIcon = %1

This example portion of the registry will be discussed. in more detailbelow when focusing on the particular types of extensions.

The preferred embodiment allows a developer to customize context menusfor objects by specifying customized static verbs and dynamic verbs. A“verb” is a kind of action that is defined by an object and itsassociated server. In the context menus, a verb is an action that isperformed in response to the selection of an associated menu item. Forexample, the menu item “Open” has an associated verb that opens the fileor object. Verbs are supported by the “MICROSOFT” OLE 2.01 protocol.Static verbs are those verbs that are registered under the “shell” key(note line 3 in the above example) within the registry 28. Static verbsmay be contrasted with dynamic verbs, which are discussed in more detailbelow. In the above example, static verbs for the “Open”, “Print”,“PrintTo” and “Preview” menu items are registered in the registry 28. Inparticular, note lines 3-11 in the above example.

An application implements a context menu handler interface IContextMenuto add more items to a context menu for a file object. The added itemsmay be object class specific or instance specific. FIG. 3 is a flowchartof the steps that are performed to add static verbs to context menus ofan object in the preferred embodiment of the present invention. First,any predefined verbs (i.e., those that the shell supports) andadditional verbs provided by a developer are registered within theregistry 28 (steps 36 and 38 in FIG. 3). The operating system 26provides functions that may be called to add entries within the registry28. In the preferred embodiment described herein, these functions areutilized by developers to create entries in the registry 28 like thoseshown in lines 4-11 of the above example. These verbs are registered inthe shell section of the registry and are added to context menus of thespecified object type (e.g., word processing documents). Theregistration of the verb specifies their menu item strings. Once theverbs are registered and the context menu has been activated, menu itemstrings associated with the verbs are displayed in the context menu(step 40). For the above example, entries for “Open,” “Print,” “PrintTo”and “Preview” are all displayed as menu item strings in the contextmenu. A user then selects one of the menu items (step 42), and the verbfor the selected menu item is activated (step 44). Path names areprovided within the registry 28 for the verbs and are used to invoke theverbs in step 44 by calling the InvokeCommand( ) function of theIContextMenu interface (which is described in more detail below).Examples of such path names are set forth at lines 5, 7, 9 and 11 in theabove example.

As discussed above, an application may also register dynamic verbs.Unlike static verbs, dynamic verbs are not statically assigned tocontext menus. FIG. 4 is a flowchart of the steps that are performed toutilize dynamic verbs in the preferred embodiment of the presentinvention. The process is initiated by registering a context menuhandler (step 46). An object class definition for the context menuobject handler class must also be provided. In the example given above,lines 13 and 14 set forth the entries for registering the context menuhandler. In particular, the class ID for the context menu handler classof objects is registered under the shellex key so that the shell knowswhat type of object to create when a context menu handler is needed.Instance specific context menus require a context menu handler. Thecontext menu handler class ID is passed to a class factory, as definedwithin Microsoft OLE 2.01, to create an object of that class. A classfactory. is an object in “MICROSOFT” OLE 2.01 that supports theIClassFactory interface and is used to create instances of an objectclass in memory. The IClassFactory interface includes a function,CreateInstance( ) for creating such instances of objects classes inmemory. Each context menu handler object is a DLL that allows developersto dynamically add verbs for a context menu. After the context menuhandler has been registered, it is used to dynamically add verbs (step48). This step will be described in more detail below. After tile verbshave been added, the context menu is displayed with the menu items forall of the verbs, including those that have been added (step 50). A userthen makes a selection that is received by the system (step 52), and theverb associated with the selected menu item is invoked by calling theInvokeCommand( ) function (step 54).

FIG. 5 is a flowchart illustrating the steps that are performed todynamically add a verb (step 48 in FIG. 4). A user initiates the processof adding verbs to a context menu by clicking a representation of anobject with the left button of mouse 14. A message is received thatindicates that the user has clicked on the object representation withthe left mouse button (step 56). The class ID of the context menuhandler is obtained (step 58). The class ID of the context menu handleris contained within the registry 28. The class ID in the example givenabove is contained in brackets on line 14. An instance of the contextmenu handler is created (i.e., an object of the specified object classis created) and the pointer for the IShellExtInit interface is requested(step 60). The “MICROSOFT” OLE 2.01 protocol provides interfaces forcreating objects of given object classes. These functions are utilizedto create an instance of a context menu handler. The IShelExtInitinterface is used by the explorer to initialize shell extension objects,like the context menu handler. This interface is defined as follows.

#undef INTERFACE

#define INTERFACE *IShellExtInit

DECLARE_INTERFACE_(IShellExtInit, Iunknown)

(

//*** IUnknown methods ***

STDMETHOD(QueryInterface) (THIS_REFRIID riid, LPVOID *ppvObj)

PURE;

STDMETHOD_(ULONG, AddRef) (THIS) PURE;

STDMETHOD_(ULONG, Release) (THIS) PURE;

// *** IShellExtInit methods ***

STDMETHOD(Initialize) (THIS_LPCITEMIDLIST pidlFolder, LPDDATAOBJECTlpdobj, HKEY hkeyProgID) PURE;

)

typedef IShellExtInit * LPSHELLEXTINIT;

IUnknown is an interface that all objects must support by definition tocomply with “MICROSOFT” OLE 2.01. Several methods from that interfaceare incorporated into the IShellExtlnit interface. Amongst the functionsadded by this interface is the Initialize( ) function. The Initialize( )function is then called to initialize the context menu handler object(step 62 in FIG. 5). A pointer to the IContextMenu interface instanceprovided by the context menu handler object is obtained (step 64). TheIContextMenu interface is defined as follows.

DECLARE_INTERFACE_(IcontextMenu, Iunknown)

(

// *** IUnknown methods ***

STDMETHOD(QueryInterface) (THIS_REFIID riid, LPVOID*ppvObj,) PURE;STDMETHOD_(ULONG, AddRef) (THIS) PURE;

STDMETHOD_(ULONG, Release) (THIS) PURE;

STDMETHOD(QueryContextMenu) (THIS_(—)

HMENU hmenu,

UINT indexMenu,

UINT idCmdFirst,

UINT idCmdLast,

UINT uFlags) PURE;

STDMETHOD(InvokeCommand) (THIS_(—)

LPCMINVOKECOMMANDINFO lpici) PURE;

STDMETHOD (GetCommandString) (This_(—)

UINT idCmd,

UINT uFlags,

UINT *pwReserved,

LPSTR pszName,

UINT cchMax) PURE;

);

Specifically, a QueryInterface( ) function call is made on the contextmenu handler object to obtain a pointer to the instance of theIContextMenu interface provided by the context menu handler object. TheIContextMenu interface includes three functions that are of interest:the QueryContextMenu( ) function, the lnvokeCommand( ) function, and theGetCommandString( ) function. The QueryContextMenu( ) function allowsthe insertion of one or more menu items to a specified menu at aspecificd location. Parameters identify the menu items, the menu, andthe location. The InvokeCommand( ) function is used to invoke a givencommand when the user selects the command, and the GetCommandString( )function is used to get the command name or help text for a specifiedcommand.

The QueryContextMenu( ) function is then called to add menu items to theidentified context menu (step 66). These menu items and their associatedverbs may then be used.

The preferred embodiment of the present invention also facilitates theextension of the shell of the operating system 26 by allowing anapplication to add property sheet pages. This capability is provided inlarge part by registering a property sheet handler for each propertysheet page to be added. FIG. 6 shows an example of a window 68 fordisplaying two property sheets, 70 and 72. The fill body of the“General” property sheet 70 is visible in FIG. 6, whereas only a tab forthe “Version” property sheet 70 is visible. In the example shown in FIG.6, the property sheets are associated with a file, denoted as “WordPad”.The property sheets list the names of properties of the file and thecurrent values of the properties. The preferred embodiment of thepresent invention allows the addition of property sheets for objectssuch as the “WordPad” file. Thus, developers can create new propertysheets that supplement those supported by the shell. For example,suppose that the “WordPad” object is provided by the operating systemand typically only has the “General” property sheet page 70 associatedwith it. The preferred embodiment of the present invention allows theaddition of the “Version” property sheet page by a shell extension.

FIG. 7 is a flowchart of the steps that are performed to allow theaddition of property sheet pages. A property sheet handler for addingproperty sheet pages is registered within the registry 28 (step 74 inFIG. 7). An example of such a registration is provided at lines 15 and16 in the above example. Later when the appropriate user actions (suchas clicking the right mouse button) are performed, a context menu with a“Properties . . . ” command is displayed on the video display 24 (step76). FIG. 8 shows an example of such a context menu 82 with a menu item84 for “Properties . . . ” The user then selects the “Properties . . . ”menu item (step 78), and the property sheet handler is invoked to addproperty sheet pages (step 80).

FIG. 9 is a flowchart showing in more detail the steps that areperformed to add property sheet pages using the property sheet handler(see step 80 in FIG. 7). A class ID for the property sheet handler isobtained by accessing the registry 28, where the registrationinformation for the property sheet handler is held (step 86). Thisretrieved class ID is then used in creating an instance of the propertysheet handler and obtaining a pointer to the IShellExtInit interface(step 88). As was discussed above, this interface includes theInitialize( ) function. The Initialize( ) function is called toinitialize the property sheet handler object that has been newly created(step 90). An interface pointer to the IShellPropSheetExt interface isobtained by calling the QueryInterface( ) function (step 92 in FIG. 9).The IShellPropSheetExt interface is defined as follows.

#undef INTERFACE

#define INTERFACE IShellPropSheetExt

DECLARE_INTERFACE_(IShellPropSheetExt, IUnknown)

(

// *** IUnknown methods ***

STDMETHOD(QueryInterface) (THIS_REFIID riid, LPVOID*ppvObj) PURE;

STDMETHOD_(ULONG, AddRef) (THIS) PURE;

STDMETHOD_(ULONG, Release) (THIS) PURE;

// *** IShellPropSheetExt methods ***

STDMETHOD(AddPages)(THIS_LPFNADDPROPSHEETPAGE lpfnAddPage, LPARAMlparam) PURE;

STDMETHOD(ReplacePage)(THIS UINT uPageID, LPFNADDPROPSHEETPAGElpfnReplaceWith, LPARAM lpParam) PURE;

The IShellPropSheetExt interface is used to allow property sheetextensions for adding additional property sheet pages. This interfaceincludes the AddPages( ) function, which adds property sheet pages foran object. The AddPages( ) function is then called to add the propertysheet pages (step 94). For each property sheet page that is added, apage object is created by calling a CreatePropertySheetPage( ) function,which is provided in the operating system 26 as part of the applicationprogram interfaces (API's) that are available.

FIG. 10 is a flowchart that shows the steps that are performed tofacilitate per-instance icons for objects. Representations of theper-instance icons, such as metafiles or bitmaps, are registered withinthe registry 28, along with an icon handler object (step 96 in FIG. 10).In the example given above, the class ID for the icon handler isregistered at line 17. When the shell of the operating system 26 needsto display a representation of the object associated with the icon, itcalls the icon handler to display the per-instance icon (step 98).

FIG. 11 shows the steps performed to display the icon using the iconhandler in more detail (see step 98 in FIG. 10). Initially, a class IDfor the icon handler is obtained by accessing the registry 28 (step100). An instance of the icon handler is created and a pointer for theIPersistFile interface instance provided the icon handler object isobtained (step 102). Using the pointer for the IPersistFile interface(defined within Microsoft OLE 2.01 ) of the icon handler object that isprovided, the shell calls the Load( ) function to initialize the iconhandler object (step 104).

An interface pointer for the IExtractIcon interface provided by the iconhandler is obtained by calling the QueryInterface( ) function. TheIExtractIcon interface is defined as follows.

DECLARE_INTERFACE_(IExtractIcon, IUnknown)

(

// *** IUnknown methods ***

STDMETHOD(QueryInterface) (THIS_REFIID riid, LPVOID *ppvObj) PURE;

STDMETHOD_(ULONG, AddRef) (THIS) PURE;

STDMETHOD_(ULONG, Release) (THIS) PURE;

// *** IExtractIcon methods ***

STDMETHOD(GetIconLocation) (THIS_(—)

UINT uFlags

LPSTR szIconFile,

UINT cchMax,

int *piIndex,

UINT * pwFlags) PURE;

STDMETHOD(ExtractIcon) (THIS_(—)

LPCSTR pszFile,

UINT nIconIndex,

HICON *phiconLarge,

HICON *phiconSmall,

UINT nIconSize) PURE;

);

typedef IExtractIcon* LPEXTRACTICON;

The GetIconLocation( ) function returns an icon location, and theExtractIcon function extracts an icon image from a specified file. TheGetIconLocation( ) function is then called to obtain a location of thefile that holds a representation of the icon (step 108). TheExtractIcon( ) function called to extract the icon representation out ofthe file and use the extracted representation to display the icon withthe shell (step 110).

Another type of shell extension handler that may be registered in thepreferred embodiment of the present invention is a copy-hook handler. Anapplication registers to copy-hook handler so that the shell of theoperating system 26 calls the copy-hook handler before the shell moves,copies, deletes, or renames a folder or printer object. The copy-hookhandler does not perform the operation itself but rather providesapproval for the requested operation. When the shell receives approvalfrom the copy-hook handler, it performs the requested file systemoperation.

FIG. 12 is a flow chart of the steps that are performed to utilize acopy-hook handler in accordance with the preferred embodiment of thepresent invention. Initially the copy-hook handler is registered withinthe registry 28 (step 112 in FIG. 12). The shell directly initializesthe copy-hook handler rather than calling the IShellExtInit orIPersistFile interfaces. A copy-hook handler supports the ICopyHookinterface, which is defined as follows:

DECLARE_INTERFACE_(ICopyHook, IUnknown) // sl

(

// *** IUnknown methods ***

STDMETHOD(QueryInterface) (THIS_REFIID riid, LPVOID * ppvObj) PURE;

STDMETHOD_(ULONG, AddRef) (THIS) PURE;

STDMETHOD_(ULONG, Release) (THIS) PURE;

STDMETHOD_(UNIT, CopyCallback) (THIS_HWND hwnd, UINT wFunc,

UINT wFlags, LPCSTR pszSrcFile, DWORD dwSrcAttribs, LPCSTR pszDestFile,DWORD dwDestAttribs) PURE;

);

typedef ICopyHook * LPCOPYHOOK;

The ICopyHook interface includes a CopyCallBack( ) function that iscalled and returns an integer value that indicates whether the shellshould perform the requested file system operation. The method mayreturn an integer value that encodes a “YES” response that specifiesthat the operation should be carried out, an integer value that encodesa “NO” response that specifies that the operation should not beperformed or an integer value that encodes a “CANCEL” response thatspecifies that the whole operation should be canceled. For example,where a batch of files is being copied, “CANCEL” cancels the entireoperation for all files on the list, whereas “NO”. skips a file on thelist that is being copied.

Returning to FIG. 12, the shell receives a request to copy, move, renameor delete a folder or printer. object (step 114). The shell then callsthe CopyCallBack( ) function for the copy-hook handler (step 116). Thefunction returns an integer value and the shell determines, based uponthe integer value, whether to perform the operation or not (step 118).

The preferred embodiment of the present invention also provides twovarieties of shell extensions that concern drag-and-drop operations. Thefirst variety is the data object extension which allows thecustomization of a source object during a drag-and-drop operation. The“MICROSOFT” OLE 2.01 protocol provides a uniform data transfer mechanismthat is described in copending U.S. application, “Uniform DataTransfer,” Ser. No. 08/199,853, filed on Feb. 22, 1994. The uniform datatransfer mechanism allows the specification of a data format in which adata transfer operation is to be performed. The uniform data transfermechanism is used during drag-and-drop operation in the preferredembodiment of the present invention. The data object extension handlerallows data to be transferred in a format that is different from thedata format of the source object. Thus, for example, a portion of textin a document may be dragged out of the document as a scrap and droppedin a file by using a data object extension handler that specifies thatthe data is to be transferred as an OLE embedding rather than a file. Asa result, the scrap is dropped as an embedding.

FIG. 13 is a flow chart illustrating the steps that are performed toutilize the data object extension handlers in the preferred embodimentof the present invention. Initially, the data object extension handlermust be registered with the registry 28 (step 120 in FIG. 13). Dataobject extension handlers are registered on a per-object class basissuch that multiple objects of a given class may use the same data objectextension handler. A drag-and-drop operation is then initiated using themouse 14 (step 122). As part of the drag-and-drop operation, the dataobject extension handler is called by the shell to extract data from thesource object into the desired format (step 124). The drag-and-dropoperation is then completed with the data being transferred in theappropriate data format (step 126).

The preferred embodiment of the present invention additionally providesdrop target extensions. Drop target extension handlers may be registeredon a per-object class basis to customize the functionality of droptargets. The “MICROSOFT” OLE 2.01 protocol provides facilities forobjects to register as drop targets so that they may receive drops indrag-and-drop operations. The drop target extension handlers customizethe behavior of drop targets.

FIG. 14 shows the steps that are performed to use a drop targetextension handler in the preferred embodiment of the present invention.Initially a drop extension handler is registered on a per-object classbasis with the registry 28 (step 128 in FIG. 14). A drag-and-dropoperation is initiated using the mouse 14 (step 130 in FIG. 14). Whenthe object is dropped, the shell calls the drop target extension handlerto determine whether the drop should be accepted and, if accepted, todetermine what steps should be performed (step 132).

An example helps to illuminate the functionality that is provided by thedrop target extension handlers. Suppose that a drop target is anexecutable file (i.e., an EXE file). In such a case, when an object isdragged and dropped on the executable file, the drop target extensionhandler is run. The drop target extension handler causes the executablefile to run using the dropped object. For example, suppose that adocument is dropped on a word processing program executable file. Insuch a case, the dropped target extension handler causes the wordprocessing program to be run to edit the document that was dropped.

It should be appreciated that the above-described extensions apply notonly to file system objects but also to network objects that may bebrowsed using the shell explorer. The appropriate handlers may beregistered in the registry 28 under a particular network provider orunder the “Network” class.

An additional extension provided by the shell of the operating system 26is the ability to add additional name spaces that are visible to theexplorer. For example, a mail folder holding mail messages may beplugged into the explorer name space. Thus, vendors may create new namespaces and simply plug the new name spaces into the explorer name space.This ability to add new name spaces is not limited to particular objecttypes. A developer may manipulate and view objects that are visible inthe explorer name space. The explorer name space is a hierarchical namespace that, in the preferred embodiment, includes file system objects,control panel items, printer objects and network objects. FIG. 15depicts an example of a user interface that is provided for theexplorer. The explorer is a part of the operating system 26 that allowsthe user to browse the explorer name space. The user interface 134 forthe explorer includes a first portion 136 that depicts the variousfolders in the hierarchy of the explorer name space: The second portion138 shows the folder contained within a particular folder that isselected from amongst those in the first portion 136. The selectedfolders may include sub-folders or simply its own contents. For example,in FIG. 15, the second portion 138 shows in more detail the contents offolder 140.

In order to incorporate a name space into the explorer name space, adeveloper needs to provide explorer extension handlers. The handlers arefolders that are integrated into the explorer name space. These handlersact as in process server DLLs as defined within the “MICROSOFT” OLE 2.01protocol. The explorer extension handlers must be registered within theregistry 28. FIG. 16 provides a flowchart of the steps that areperformed to facilitate the integration of such additional name spacesinto the explorer name space. First, the explorer extension handler mustbe registered within the registry 28 (step 142 in FIG. 16). The explorerextension handlers may be registered under the “My Computer” directorywithin the explorer name space or under other file system directories.To put an extension under the “My Computer” directory, the class ID ofthe explorer extension handler should be registered under“HKEY_MACHINE\Software\Windows\CurrentVersion\Explorer”. When, instead,the class ID of the explorer extension handler is to be registered in afile system directory, a special file system directory should becreated.

The explorer extension handler is then called to display and gain accessto the extended name space of the handler (step 144 in FIG. 16). FIG. 17shows in more detail the steps that are performed to realize thedisplaying and accessing of the extended name space. An instance of theexplorer extension handler is created and an interface pointer to theinstance of the IPersistFolder that the handler provides is obtained(step 246 in FIG. 17). The IPersistFolder interface is defined asfollows.

#undef INTERFACE

#define INTERFACE IPersistFolder

DECLARE_INTERFACE_(IPersistFolder, IPersist) // fld

(

// *** IUnknown methods ***

STDMETHOD(QueryInterface( (THIS_REFIID riid, LPVOID * ppvObj) PURE;

STDMETHOD_(ULONG, AddRef) (THIS) PURE;

STDMETHOD_(ULONG, Release) (THIS) PURE;

// *** IPersist methods ***

STDMETHOD(GetClassID) (THIS_LPCLSID lpClassID) PURE;

// *** IPersistFolder methods ***

STDMETHOD(Initialize) (THIS_LPCITEMIDLIST pidl) PURE;

);

The IPersistFolder interface includes the Initialize( ) function forinitializing a shell folder object. In this case, the new name space isa shell folder object. The Initialize( ) function is then called (step148). A pointer to the IShellFolder interface is obtained by calling theQueryInterface( ) function (step 150 in FIG. 17). The IShellFolderinterface includes a number of functions that allow the explorer to viewthe objects within the added name, space and to manipulate the objectscontained therein. In particular, the IShellFolder interface is definedas follows.

DECLARE_INTERFACE_(IShellFolder, IUnknown)

(

// *** IUnknown methods ***

STDMETHOD (QueryInterface) (THIS_REFIID riid, LPVOID *ppvObj) PURE;

STDMETHOD (ULONG, AddRef) (THIS) PURE;

STDMETHOD_(ULONG, Release) (THIS) PURE;

// *** IShellFolder methods ***

STDMETHOD(ParseDisplayName) (THIS_HWND hwndOwner, LPBC pbcReserved,LPOLESTR lpszDisplayName,

ULONG* pchEaten, LPITEMIDLIST * ppidl, ULONG *pdwAttributes) PURE;

STDMETHOD(EnumObjects) (THIS_HWND hwndOwner, DWORD grfFlags,LPENUMIDLIST * ppenumIDList) PURE;

STDMETHOD(BindToObject) (THIS LPCITEMIDLIST pidl, LPBC pbcReserved,REFIID riid, LPVOID * ppvOut) PURE;

STDMETHOD(BindToStorage) (THIS_LPCITEMIDLIST pidl, LPBC pbcReserved,REFIID riid, LPVOID * ppvObj) PURE;

STDMETHOD(CompareIDs) (THIS_LPARAM lParam, LPCITEMIDLIST pidl1,LPCITEMIDLIST pidl2) PURE;

STDMETHOD(CreateViewObject) (THIS_HWND hwndOwner, REFIID riid, LPVOID*ppvOut) PURE;

STDMETHOD(GetAttributesOf) (THIS_UINT cidl, LPCITEMIDLIST * apidl,ULONG * rgflnOut) PURE;

STDMETHOD(GetUIObjectOf) (THIS_HWND hwndOwner, UINT cidl,LPCITEMIDLIST * apidl, REFIID riid, UINT * prgfInOut LPVOID * ppvOut)PURE;

STDMETHOD(GetDisplayNameOf) (This_LPCITEMIDLIST pidl, DWORD uFlags,LPSTRRET lpName) PURE;

STDMETHOD(SetNameOf) (This_HWND hwnd([O?]wner, LPCITEMIDLIST pidl,LPCOLESTR lpszName, DWORD uFlags, LPITEMMIDLIST * ppidlOut) PURE;

);

These functions are called as needed to perform the needed behavior toview and manipulate the objects of the added name space (step 152 inFIG. 17). Of particular interest to the preferred embodiment of thepresent invention is the CreateViewObject( ) function that creates aview object that supports the IShellView interface. Also of interest inthe IShellFolder interface is the GetUIObjectOf( ) fiction that createsa UI object (e.g., an icon) to be used for specified objects. TheEnumObjects( ) function is used to enumerate the objects within the newobject space.

The IShellView interface is defined as follows:

DECLARE_INTERFACE_(IShellView, IOleWindow)

(

// *** IUnknown methods ***

STDMETHOD (QueryInterface) (THIS_REFIID riid, LPVOID FAR* ppvObj) PURE;

STDMETHOD_(ULONG, AddRef) (THIS) PURE;

STDMETHOD_(ULONG, Release) (THIS) PURE;

// *** IOleWindow methods ***

STDMETHOD(GetWindow) (THIS_HWND FAR* lphwnd) PURE;

STDMETHOD(ContextSensitiveHelp) (THIS_BOOL fEnterMode) PURE;

// *** IShellView methods ***

STDMETHOD(TranslateAccelerator) (THIS_LPMSG lpmsg) PURE;

STDMETHOD(EnableModeless) (THIS_BOOL fEnable) PURE;

STDMETHOD(UIActivate) (THIS_UINT uState) PURE;

STDMETHOD(Refresh) (THIS) PURE;

STDMETHOD(CreateViewWindow) (THIS_IShellView FAR *lpPrevView,LPCFOLDERSETTINGS lpfs, IShellBrowser FAR * psb, RECT FAR* prcView, HWNDFAR *phWnd) PURE;

STDMETHOD(DestroyViewWindow) (THIS) PURE;

STDMETHOD(GetCurrentInfo) (THIS_LPCFOLDERSETTINGS lpfs) PURE;

STDMETHOD(ForwardControlMsg) (THIS_UINT id, UINT uMsg, WPARAM wParam,LPARAM lParam, LRESULT FAR* pret) PURE;

STDMETHOD(AddPropertySheetPages) (THIS_DWORD dwReserved,LPFNADDPROPSHEETPAGE lpfn, LPARAM lparam) PURE;

STDMETHOD(SaveViewState) (THIS) PURE;

STDMETHOD(SelectItem) (THIS_LPCVOID lpvID, UINT uflags) PURE;

);

The shell uses the IShellView interface to display information in thesecond portion 138 (FIG. 15) of the explorer. The explorer calls theCreateViewWindow( ) function to allow a name space extension to create aview window for a folder. The explorer notifies state changes by callingthe UIActivate( ) function.

The shell explorer/folder frame window that provides the first portion136 of the explorer supports the IShellBrowser interface. This interfaceis defined as follows:

DECLARE INTERFACE (IShellBrowser, IOleWindow)

(

// ***IUnknown methods ***

STDMETHOD (QueryInterface) (THIS_REFIID riid, LPVOID FAR* ppvObj) PURE;

STDMETHOD_(ULONG, AddRef) (THIS) PURE;

STDMETHOD (ULONG, Release) (THIS) PURE;

// *** IOleWindow methods ***

STDMETHOD(GetWindow) (THIS_HWND FAR* lphwnd) PURE;

STDMETHOD(ContextSensitiveHelp) (THIS_BOOL fEnterMode) PURE;

// *** IShellBrowser methods *** (same as IOleInPlaceFrame)

STDMETHOD(InsertMenus) (THIS_HMENU hmenuShared, LPbLEMENUGROUPWIDTHSlpMenuWidths) PURE;

STDMETHOD(SetMenu) (THIS_HMENU hmenuShared, HOLEMENU holemenu, HWNDhwndActiveObject) PURE;

STDMETHOD(RemoveMenus) (THIS_HMENU hmenuShared) PURE;

STDMETHOD(SetStatusText) (THIS_LPCOLESTR lpszStatusText) PURE;

STDMETHOD(EnableModeless) (THIS_BOOL fEnable) PURE;

STDMETHOD (TranslateAccelerator) (THIS_LPMSG lpmsg, WORD wID) PURE;

// *** IShellBrowser methods ***

STDMETHOD(BrowseObject) (THIS_LPMONIKER pmk, UINT wFlags) PURE;

STDMETHOD(GetViewStateStream) (THIS_DWORD grfMode, LPSTREAM FAR *ppStrm)PURE;

STDMETHOD(GetControlWindow) (THIS_UINT id, HWND FAR* lphwnd) PURE;

STDMETHOD(SendControlMsg) (THIS_UINT id, UINT uMsg, WPARAM wParam,LPARAM lParam, LRESULT FAR* pret) PURE;

STDMETHOD(QueryActiveShellView) (THIS_struct IShellView FAR** ppshv)PURE;

STDMETHOD (OnViewWindowActive) (THIS_struct IShellView FAR* ppshv) PURE;

STDMETHOD (AddViewPropertySheetPages) (THIS_DWORD dwReserved,LPFNADDPROPSHEETPAGE lpfn, LPARAM lparam) PURE;

STDMETHOD (SetToolbarItems) (THIS_LPTBBUTTON lpButtons, UINT nButtons,UINT uFlags) PURE;

);

The shell explorer/folder frame calls its CreateViewObject( ) functionto create an object that supports the IShellView interface. The shellexplorer/folder frame calls its CreateViewWindow function to create thefirst portion 136 of the explorer. A pointer to the IShellBrowserinterface is passed to the view object that supports the IShellViewinterface as a parameter to the CreateViewWindow( ) function call.

Thus, in order to add a name space to the explorer name space, theextension handler must support the IPersistFolder and IShellFolderinterfaces. In addition, each object in the new name space must supportthe IShellView interface. The Shell/Explorer folder frame must supportthe IBrowser interface.

FIG. 18 is a flowchart illustrating the steps that are performed whenthe user opens a shell folder for an extended name space or one of thesubfolders contained within the shell folder for the extended namespace. Initially, the user opens the folder or subfolder in tileextended name space (step 154 in FIG. 18). The folder or subfolder istypically displayed in the first area 136 (FIG. 15) of the explorerwindow 134 Tile folder or subfolder is opened by double clicking on thefolder or subfolder with the mouse 14 or by selecting an open optionfrom the file menu. A view object is then created by calling theCreateViewObject( ) within the IShellFolder interface (step 156 in FIG.18). The view object knows how to display the contents of the folder orsubfolder. A view window for the folder or subfolder is then created bycalling the CreateViewWindow( ) function to create a view window for thefolder or subfolder. The view object then displays information in theview window, as dictated by the folder or subfolder. Thus, for example,the contents of the folder or subfolder may he shown in a second portion138 of the explorer window 134 (FIG. 15).

The approach of the preferred embodiment of the present inventiondiffers greatly from approaches adopted by conventional operatingsystems. In conventional operating systems, the shell is typicallyresponsible for displaying any information about file system objectswithin a file manager. In the preferred embodiment of the presentinvention, in contrast, the objects are responsible for displaying theircontents within the explorer. For example, each folder and subfolderwithin an extended name space is responsible for displaying its contentswhen opened using the explorer. This allows users to easily discern thecontents of such folders and subfolders.

While the present invention has been described with reference to apreferred embodiment thereof, those skilled in the art will appreciatethat variations in form and detail may be made without departing fromthe intended scope of the present invention as defined in the appendedclaims.

The shell extensions of the preferred embodiment of the presentinvention are described in more detail in the attached appendix.

The embodiments of the invention in which an exclusive property orprivilege is claimed are defined as follows:
 1. A method of generating aproperty sheet having at least a shell supported property sheet page andat least an application supported property sheet page in a dataprocessing system having a video display and a processor running anoperating system that includes a shell, the method comprising: providingat least one object associated with an application installed under theoperating system, each object belonging to an object class; providing ashell supported property sheet page defined by the shell in associationwith the object class, the shell supported property sheet pagepresenting a shell supported property; providing at least oneapplication supported property sheet page defined by the application inassociation with the object, the application supported property sheetpage presenting at least one application supported property; integratingthe application supported property sheet page and the shell supportedproperty sheet page into the property sheet; and in response to arequest to display one or more properties associated with the object,displaying the property sheet to provide access to the shell supportedproperty sheet page and the application supported property sheet page.2. The method according to claim 1 wherein the operation of providing atleast one application supported property sheet page comprises: receivingthe application supported property associated with the object; andgenerating the application supported property sheet page to present theapplication supported property.
 3. The method according to claim 1wherein the operation of providing at least one application supportedproperty sheet page comprises: providing a property sheet handler foreach application supported property sheet page associated with theobject, the property sheet handler being provided by the applicationprogram.
 4. The method according to claim 3 wherein the operation ofproviding an application supported property sheet page comprises:registering the property sheet handler in the registry, the propertysheet handler remaining independent of the operating system.
 5. Themethod of claim 3 wherein the integrating operation comprises: invokingthe property sheet handler to retrieve the application supportedproperty sheet page for integration into the property sheet.
 6. Themethod according to claim 3 wherein the shell supported property sheetpage is associated with the property sheet, and the integratingoperation comprises: obtaining a class identifier for the property sheethandler; creating an instance of the property sheet handler, based onthe class identifier; defining an interface for adding the applicationsupported property sheet page to the property sheet, based on theinstance of the property sheet handler; and adding the applicationsupported property sheet page to the property sheet, through theinterface.
 7. A computer-readable medium containing instructions forcarrying out the method in any one of claims 1-6.
 8. A computer-readablemedium as recited in claim 7 wherein the computer-readable medium is acommunications medium.